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SECTION 1 


INTRODUCTION 


1.1 Background 

The objectives of this element of the NASA Satellite Communications Applications 
Research (SCAR) Program are to develop new advanced on-board satellite capabilities that 
will enable the provision of new services, namely interim and full Integrated Services 
Digital Network (ISDN) services via satellite and to provide a system analysis of futuristic 
satellite communications concepts, namely broadband services via satellite. 

This aspect of the NASA SCAR Program provides a research and development effort to: 

1) develop basic technologies and concepts to use the on-board processing and 
switching capabilities of advanced satellites that will enable the provision of 
interim and full ISDN services and 

2) provide a systems and requirements analysis of future satellite 
communications concepts based on a new generation of broadband 
switching and processing satellites. 

These objectives will be achieved in part via modeling and simulation of ISDN satellites as 
part of the ISDN terrestrial network. Models of the Interim Service ISDN Satellite (ISIS) 
and the Full Service ISDN Satellite (FSIS) will exercised using discrete event simulation 
techniques. 

To provide meaningful results the network model that represents the subsystems of the 
advanced satellite system design must provide a proper level of abstraction of the real world 
advanced ISDN communications satellite design parameters. 

An end-to-end network view must be developed using the framework of the CCITT and 
ANSI standards to ensure that ISDN procedures and protocols are properly implemented to 
permit meaningful evaluation and analyses ISDN communications satellite designs. 
Network performance measures must assess the overall network in terms of speed, 
capacity, accuracy, access reliability, and availability. Component performance 
measurements must provide insight into the engineering performance of the system. The 
network model must be capable of generating performance measures including propagation 
delay, signal degradation, message queue lengths, network node switching delay and raw 
throughput. 

1.2 Scope 

This task completion report documents the network model associated with the ISIS design. 
The process and methodology is applicable to the ISIS and the FSIS systems as described 
in Figure 1.1-1, "NASA/SCAR Approaches for Advanced ISDN Satellites". The ISIS 
Network Model design represents satellite systems like the Advanced Communications 
Technology Satellite (ACTS) orbiting switch. 

ACTS will be controlled by a Master Ground Station (MGS) shown in Figure 1.2-1, 
"Closed User-Oriented Scenario". A user of the ACTS satellite orbiting switch request 
services from the MGS, a combination of the NASA Ground Station (NGS) and the Master 
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Figure 1.1-1 NASA/SCAR Approaches for Advanced ISDN Satellites 
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Closed User-Oriented Scenario 










Control Station (MCS). The MGS, in turn, commands the satellite to switch the 
appropriate communication channel. 

The ultimate aim of this element of the SCAR Program is to move these MGS functions on- 
board the next generation ISDN communications satellite as shown in Figure 1.2-2, 
"Advanced ISDN Satellite". The technical and operational parameters for the advanced 
ISDN communications satellite design will be obtained from an engineering software model 
of the major subsystems of the ISDN communications satellite architecture. Discrete event 
simulation experiments will be performed with the model using various traffic scenarios, 
design parameters, and operational procedures. The data from these simulations will be 
analyzed using the NASA SCAR performance measures discussed in previous reports. 

1.3 Document Overview 

This task completion report begins by describing the use of modeling and simulation 
techniques to determine the design parameters for the SCAR advanced ISDN 
communications satellite design. An overview of the modeling and simulation tasks 
includes a brief description of the four software programs of that effort. 

Particular attention is given to the ISIS network modeling. The two main sections of this 
task report are Network Modeling and ISIS Network Model. The Network Modeling 
Section describes the modeling process which is based on discrete event simulation 
techniques. A brief description of the traffic model database is followed by a description 
of the scenario generation process that provides Scenario Traffic Files (STFs) for the 
simulation. The ISIS Network Model Section develops the concepts, definitions and 
purposes of the Advanced Communications Technology Satellite (ACTS)-like network 
model. A summary of the task completion report is provided. 
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Figure 1.2-2 Advanced ISDN Satellite 





SECTION 2 


MODELING AND SIMULATION 


2.1 Modeling and Simulation Objective 

The objective of this modeling and simulation project is to design and develop software 
models that can be used to simulate those aspects of the ISDN communications satellite 
with sufficient fidelity to assist in its design. This end-to-end simulation will include 
sufficient functionality to demonstrate the interactions between each of the four modeling 
and simulation phases: database generation, scenario generation, simulation run, and 
product generation. A description of each of these software programs is abbreviated in 
order to focus on the ISIS Network Model itself. 

2.2 Major Modeling and Simulation Programs 

The ISDN communications satellite end-to-end simulation is shown in Figure 2.2-1, "End- 
to-End Model Architecture". Each program is physically and functionally separated by 
input/output data files. This separation ensures that each program is independent and that 
each project phase is separate from the others. The only link between these programs is the 
data file they share. 

Each program is briefly described in the following sections in order to provide an overview 
of the modeling and simulation process as well as to provide the context for the ISIS 
Network Model. 

2.2.1 Database Generation Program 

The Database Generation (DbGen) program assembles the major ISDN user characteristics 
into a machine readable database. For this NASA SCAR effort the traffic model consists of 
a number of databases: the City Reference DB, ISDN User vs Industry DB, Application vs 
Industry DB, Application vs Time DB, and Application vs Bearer Services DB. Figure 
2.2.1-1, "CONUS City Locations for NASA SCAR Traffic Model Database", shows the 
cities that are part of the traffic model. Those cities outlined with an ellipse identify the 
ACTS-east cities. Those cities outline with a rectangle identify the "ACTS-west" cities and 
the blackened squares depict the fixed antenna cities. The east/west city clusters are 
separated by a dashed line. The figure shows that the NASA SCAR traffic model is well 
aligned with the cities of interest for ACTS. That traffic model database represents the 
ISDN traffic for these cities and is the principal input to the scenario generation process. 

2.2.2 Scenario Generation Program 

The Scenario Generation (ScenGen) program selects the traffic model database entries that 
describes a scenario of ISDN users together with the statistical information of the ISDN 
services requested. The ScenGen program uses entries from the user traffic model 
database and engineering parameter databases to generates a list of time ordered, initiating 
discrete events. The discrete event list is call a Scenario Traffic File (STF). The STF is 
used to initialize the model for a specific advanced ISDN communications satellite design 
and to exercise that satellite design using the requests for ISDN services dictated by the 
ISDN user traffic. 
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Figure 2.2-1 End to End ISDN Model Architecture 
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2.2.3 


Simulation Run Program 


The Simulation Run (SimRun) program consists of a model of the real world 
communications network of the major ISDN communications satellite components. Each 
of these ISDN communication components is represented by a block diagram within the 
overall architecture of the complete network. As shown in Figure 2.2.3- 1, "Simulation 
Run Program", the SimRun program essentially reads each discrete event from the (STF), 
takes the appropriate action, and logs that action and the corresponding results in a 
measurement save (MSAVE) file. The appropriate action taken by the simulation includes 
allocating and releasing communication resources, denying specific services, and calling 
other processes in-tum. The principal topics of this task completion report are developed in 
Section 3.0 for the generic Network Modeling aspects associated with SimRun and Section 
4.0 which addresses the specific ISIS Network Model to be used in SimRun. 

2.2.4 Product Generation Program 

The Product Generation (ProdGen) program reads the data in the MSAVE file and 
analyzes these data in accordance with specific algorithms. It is envisioned that there 
would be as many product generation programs as there are ISDN communications satellite 
issues to be studied: throughput, response time, trace, delay, call blocking, busy-minute, 
busy-hour, etc. Each ProdGen program is tailored to a particular area of ISDN 
communications satellite design. Performance measures will be used as criteria to evaluate 
the design parameters, operational procedures and degree of ISDN communications 
standard compliance of the particular ISDN communications satellite design. 
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Figure 2.2.3- 1 Simulation Run Program 



SECTION 3 


NETWORK MODELING 


3.1 Technical Concept 

Experimental research must be based a sound foundations: a clear understanding of the 
system under study. That understanding for this NASA SCAR effort includes using 
network modeling and simulation of an ISDN communications satellite as the core technical 
concept for addressing its design. 

This network modeling will clearly delineate the network architecture (as defined by the 
network methodology, the number and kinds of communications elements and how those 
elements are configured), network operations (including link and network layer protocols 
and how network functions are distributed among communications elements), and system 
constraints (imposed both by the network and by the operational requirements). 

3.2 Network Model and Simulator Development 

A discrete event simulator for the ISIS was defined based on the Phase I network model of 
the ISIS communications architecture. The traffic model database and the scenarios, also 
developed in Phase I, were used to define ISIS Network Model simulator inputs. The 
simulator outputs will be defined by the performance measures established in Phase I and 
will be used to evaluate overall ISDN communications satellite system performance. 

3.3 Simulator Development 

ISDN is based on the Open System Interconnection (OSI) Reference Model. Though the 
simulations will focus on the second (data link) and third (network) layers to evaluate the 
performance of routing, acknowledgement, congestion control, and other protocol driven 
functions, this ISIS Network Model will also address the time-out issues relate to the first 
(physical) layer. Although physical characteristics of the system will not be simulated, the 
effects of the physical conditions will be included parametrically. For example, the cases 
involving heavy rain, severe signal degradation, and higher error rates are examined in 
terms of protocol performance when multiple transmission are required. Instead of 
calculating a link budget where all signal losses and gains are summed and converting the 
signal-to-noise ratio to a bit-error rate, the simulator will take the error rate on a particular 
link as input. Such techniques reduce the complexity of the simulator, while providing the 
same level of information about link and network layer protocols. 

3.4 Generic Network Model 

Figure 3.4-1, "Generic Network Model Block Diagram", shows the major subsystems of a 
communications architecture for a communications satellite with two satellite terminals each 
supporting three users. For this model the subsystems associated with the satellite 
terminals consist of an uplink transmitter and transmitting antenna, a downlink receiver and 
receive antenna, three users generating traffic, and a multiplexer/demultiplexer that 
combines and separates this traffic. The satellite is modeled by corresponding receivers, 
transmitters, antennas, an on-board switch, and an on-board processor that decodes 
received commands, controls the switch, and generates response traffic. 
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3.5 


Generic Network Model Subsystems 


Each of the communications subsystems in the network model design is represented by a 
software module that performs the functions of that communication component. Figure 
3.5-1, "SCAR Network Model Systems”, shows the generic network model presented in 
Figure 3.4-1 as an interconnected software module. Each module has parameter (p) input 
that determines that module's characteristics. For an antenna: p includes such things as the 
gain, beamwidth, scan rate, dwell time, etc. For a receiver: p includes frequency, burst 
rates, receiver threshold, receiver delay, etc. For a processor: protocol repertoire, 
processing time, clock frequency, number of ISDN resources, etc. In general each model 
module has a p-set that determines the design characteristics. These p's are input via the 
traffic file before the simulation run begins. They determine the design baseline for each 
communications subsystem. 

The initial discrete events (E) are part of the STF and are executed as a function of time 
depending on the scenario that generated them. Each of the precipitating events (E) is 
destined for a particular module in the simulation. That module processes discrete events 
(E) and takes actions accordingly. Many of these actions include generating response 
events (e) for another module. The response events (e) are integrated with the initial events 
(E) via the (stf) to be executed at their respective times. For ISDN protocols, a single initial 
discrete event (E) will generate many response events (e). The simulation process 
continues the execution of the time ordered event list until the simulation end. The 
technical data generated by the simulation is obtained from a Measurement Save (MSave) 
file. Every time an discrete event is presented to a module its identity and its time of arrival 
is saved on the MSave file (M). Also, all resource allocations, resource releases, resource 
denials, event generations, and the status of every module is saved on the MSave file (M) 
together with the time of their occurrence, The MSave file has a complete time ordered 
history of every event, action, and status of every module for the entire simulation. That 
MSave file can be analyzed to generate any technical and operational product imaginable. 

3.6 Generic Network Model Software 

The simulation software inside each module determines its communication characteristics 
and responses. Figure 3.6-1, "SCAR Network Model Simulation Software", depicts the 
software flow chart for a single module - Proc. In that example, when the processor 
function (Proc) receives the event (Sig#27) it first reports that event and time to MSave 
(M). 


The software then determines if the requested resources are available. At the beginning of 
the simulation parameter (pi) allocated a number (#1) of these resources to Proc for 
allocation. If none of those resources are now available, Proc sends a "No Resources 
Available" to the MSave. Proc then clears all Sig#27 items and Returns control to the 
simulation timing routine. On the other hand if resources were available, Proc would 
allocate and adjust those resources; report the allocation to MSave; and activate the next 
process in the sequence. The activation time for the next process will be calculated using 
the processing delay value of #2 micro-seconds for this operation obtained from a p2 
assignment at the start of the simulation. 

The same software will be re-used with different parametric values for similar functions 
such as antenna, receiver, processor, etc. This will result in the generation of less 
simulation code for a given software development. 
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Figure 3.6-1 SCAR Network Model Simulation Software 







3.7 


ISIS Multi-Terminal SCAR Model 


The Figure 3.7-1, "ISIS Multi-Terminal SCAR Model", generically depicts ISIS as a 
satellite-based switch using ground control to provide communications services between 
terminals on the left. This same model is also capable of connecting central offices on the 
right. Such a model can be used as a vehicle for analyzing the protocol messages flow 
among all the users connected to the satellite. The next section develops a specific ISIS 
Network Model associated with the ACTS Program. 


3-6 


rTr ■ Government / 

U 1 1 ■ Systems ( nasa - scar 



3 


Figure 3.7-1 ISIS Multi-Terminal SCAR Model 


























SECTION 4 


ISIS NETWORK MODEL 


4.1 Introduction 

The modeling context of the previous sections are now applied to an ISIS Network Model 
for an ACTS-like system. This ISIS model baseline uses the "Approach 2k" Alternative 
described in the ACTS ISDN Study Mid-Term Review p resented to NASA Lewis Research 
Center, by COMSAT Laboratories, on June 21, 1991. The "Approach 2A" nomenclature 
is also used when possible. The ISIS Network Model will focus on the ISDN circuit 
switched protocols: call control (Q.93 1/1.451), LAPD (Q.921/I441), PRI (I.I431), BRI 
(1.430), and SS7 (ISUP). The ISIS model will leave issues such as network management, 
packet switching, and physical level (layer 1) fault isolation to the subsequent FSIS 
Network Model phase. The D Channel protocol messages and their associated timing, 
propagation, processing, and execution are the main concerns of the ISIS model The B 
channels are modeled as resources to be allocated and released in proportion to their 
availability. 

As illustrated in Figure 4.1-1, "ACTS/ISDN Signal Flow", the ISIS system will provide 
the ISDN user access to ACTS via VSATs connected with ISDN Satellite Terminal 
Adapters (ISTAs). The ACTS will be controlled by a Master Ground Station (MGS) 
consisting of a NASA Ground Station (NGS) and the Master Control Station (MCS). The 
ISIS Network Model will use D channel signalling and those parts of the ISUP as 
described in "Approach 2A". This approach will enable an advanced satellite like ACTS to 
provide nation-wide, narrowband ISDN. The ISIS model will use the proposed ACTS call 
controls and baseband processor switching architecture. 

The ultimate aim of this aspect of this SCAR Program is to move the ISDN functions on- 
board the satellite for the next generation ISDN communications satellite design. The ISIS 
model will provide a starting point for that design. Those technical and operational 
parameters for the ISDN advanced communications satellite design will be further 
developed as part of the Full Service ISDN Satellite (FSIS) network model in the next 
phase of this SCAR Program. 

In both cases, ISIS and FSIS, the design analyses will be obtained from an engineering 
software models of the major subsystems of the ISDN communications satellite architecture 
and their appropriate ground terminations. Discrete event simulation experiments will be 
performed with the model using various traffic scenarios, design parameters, and 
operational procedures and performance measures. 

4.2 Definition and Purpose 

The ISIS Network Model consists of a number of VSATs connected to ACTS via a single 
hop. The VSATs will exchange narrowband ISDN traffic on a demand access, circuit 
switched basis. The purpose is to investigate the throughput, response time, blocking 
probability, and robustness of ISIS Network Model in a benign environment to provide a 
performance measures baseline for the FSIS Network Model and to investigate protocol 
timing issues at the lower layer levels. Particular attention will focus on the timing and 
time-outs associated with the ISDN physical layer protocol. The FSIS model will deal with 
issues such as: packet switching on the B and D channels, full SS7 protocols, weather, 
and direct connectivity to an ISDN public switched network (IPSN). 
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Figure 4.1-1 ACTS/ISDN Signal Flow 







4.3 


ISIS Model Components 


As shown in Figure 4.3-1, "ISIS Network Model Communication Components", the ISIS 
model consists of a number of components that can be related to "Approach 2A". The 
components include: the ACTS satellite, the Master Ground Station (MGS) representing the 
NASA Ground Station (NGS) and the Master Control Stations (MCS), the VSAT user 
terminals representing the Redcom MSP + SP + LBR-2, ISDN Satellite Terminal Adapters 
(ISTA), ISDN telephone users, the earth/space propagation and the ISDN interfaces. The 
following sections will describe each of these ISIS model components in terms of the 
modeling process that implements them. Section 4.4 describes these modeling processes 
and Section 4.5 will collect these processes and communication components into a 
complete end-to-end view of the ISIS Network Model. 

4.3.1 ACTS Satellite Component 

The advanced ISDN communications satellite design under the NASA SCAR Program 
uses as its design starting point the Advanced Communications Technology Satellite 
(ACTS) as a switch in orbit. That ACTS orbiting switch is presently controlled by a 
Master Ground Station (MGS) which consists of a combination of the NASA Ground 
Station (NGS) and the Master Control Station (MCS) - (NGS/MCS). From an ISDN 
traffic view, the ACTS orbiting switch consists of a baseband processor (BBP) that is 
capable of relaying communications protocols to the MGS and receiving switching 
commands from the MGS. 

A user of the ACTS satellite requests services from the MGS using ISDN protocols. 
Those ISDN protocols are routed to the MGS via a number of ISDN and SS7 protocol 
conversion processes. These protocols are converted to inbound order-wire (IBOW) 
messages for processing and action. The MGS process these IBOW messages and issues 
the appropriate BBP command messages to the the ACTS satellite via outbound order-wire 
(OBOW) messages. 

The ACTS satellite operations are modeled by an uplink receiving antenna (RxAnt 30) and 
receiver (Rx 30) that are connected to the ACTS orderwire processor (ACTSOW). See 
Figure 4.5-1. The ACTSOW routes the IBOW to the ACTS downlink and the OBOW to 
the on-board baseband processor (ACTSBBP). The ACTSBBP acts on all OBOW 
commands and sends BBP status messages to the MGS via the ACTS downlink. The 
ACTS downlink is modeled by a downlink transmitter (Tx20) and an associated downlink 
transmitting antenna (TxAnt20). Both the downlink and uplink propagation are modeled 
by propagation (Prop) process that delays these messages as a function of distance between 
the satellite and the ground terminal. 

4.3.2 Master Ground Station Component 

The ACTS Master Ground Station (MGS) receives IBOW and the BBP status messages 
from the ACTS satellite. It processes these messages and then generates and transmits the 
appropriate OBOW and BBP command messages to the ACTS satellite. 

The MGS operations are modeled by a downlink receiving antenna (RxAnt20) and receiver 
(Rx20) that are connected to the MGS orderwire processor (MGSOW). The MGSOW 
routes the IBOW to the MGS processor (MGSProc). The MGSProc processes all IBOW 
and generates OBOW and BBP command messages that are uplinked to the ACTS satellite. 
The MGS uplink is modeled by an uplink transmitter (Tx30) and an associated uplink 
transmitting antenna (TxAnt30). Both the downlinks and uplinks propagation are modeled 
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by the propagation (Prop) process that delays the signal as a function of distance between 
the satellite and the ground terminal. 

4.3.3 VS AT User Terminal Component 

The VSAT user terminal represents the ISDN user entry into the ACTS satellite. For the 
ISIS Network Model, the VSAT is equivalent to the Redcom MSP plus the signal 
processor (SP) plus the Low Bit Rate Terminal 2 (LBR-2). The VSAT connects the user 
with U-interface and connects to the ACTS satellite with a propagation (Proc) interface. As 
such the VSAT represents the exchange termination (ET) for the user. The VSAT converts 
ISDN protocol messages into TDMA uplink of IBOWs in one direction and converts the 
downlink OBOWs to ISDN protocols in the other direction. 

The VSAT operations are modeled by a TDMA downlink receiving antenna (RxAnt20) and 
receiver (Rx20) that are connected to the VSAT orderwire processor (VSATOW). The 
VSATOW routes the OBOW to the VSAT processor (VSATProc). The VSATProc 
translates all OBOW messages into ISUP protocols messages. Process ISUP (ISUP) 
converts these ISUP protocol messages and passes them to the Layer 3 network protocol 
processor (Q931). The Q931 process in turn passes these protocols to the Layer 2, data 
link and Layer 1, physical protocol converters using the Q921 and 1431 processes, 
respectively. The 1431 process provides the 1544 kbps primary rate ISDN interface at the 
U-interface level. 

The VSAT TDMA uplink operations are modeled in similar manner to convert ISDN 
protocols to uplink IBOW messages. The ISDN protocols come to the 1431 process via the 
U interface. The Q931, and ISUP processes pass these protocols up the OSI layers to the 
VSATOW process for conversion into a TDMA format for uplink transmission via Tx30 
and TxAnt30 to ACTS. 

Both the downlink and uplink propagation are modeled by the propagation (Prop) process 
that delays the protocol messages as a function of distance between the satellite and the 
ground terminal. 

4.3.4 ISDN Satellite Terminal Adapter Component 

The ISDN satellite terminal adapter (ISTA) represents the user’s NT2 and NT1 connection 
between the user at the S-interface and the exchange termination (ET) at the U-interface. It 
represents protocol conversion necessary for aggregating a number of BRI services in a 
PRI link for ultimate translation into a TDMA uplink. For a downlink the ISTA also 
converts a PRI connection into a BRI service connections. 

The ISTA operations are modeled by a Layer 1, physical protocol conversion process 
(1430) process at the S-interface. These protocols are converted up and down the OSI 
layers to match the S-interface BRI protocols to the U-interface PRI protocols. The 
sequences of processes are: 1430, Q921, Q931, Q931, Q921, and 1431 in the S-interface to 
U-interface direction. The reverse sequence of processes models the U-interface to T- 
interface direction. 

4.3.5 ISDN Telephone User Component 

For the ISIS Network Model the ISDN telephone represents the source and sink of all 
ISDN call connections. The off-hook and on-hook conditions are used as a starting point 
for the call connection protocol sequences that are converted along the OSI layer chain to 
the S-interface of the network termination (NT). 
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The ISDN Telephone operations are modeled by a human interface process (ISDNTel) that 
provides the on-hook and off-hook conditions. These ISDNTel processes act as sources 
by generating a Layer 3 protocol sequence using the Q931 messages that are converted 
down the OSI layers by the Q931, Q921 and 1430 processes to S-Interface signals. The 
reverse sequence of these processes models the S-interface to ISDNTel direction. 

4.3.6 Propagation Component 

Both the downlink and uplink in the ISIS Network Model account for the time delay 
experienced by a signal as it propagates between the ACTS satellite and any ground 
terminal. A significant amount of time is spent in signal propagation. 

Propagation is modeled by a single propagation (Prop) process that delays the signal as a 
function of distance between the satellite and the ground terminal. That distance depends 
on the satellite orbit and topology and the terminal distribution. These propagation 
distances change dramatically as a function of time and points of origin and destination. 

4.3.7 S-Interface Components 

The S-interface component provides the BRI connectivity between the ISDN user and the 
ISTA. This connection is similar to most wiring configuration which can be used to 
connect to an NT. These configurations can be divided into three types: 

• A single installation where only one terminal is connected to an NT 

• A multi-terminal installation where several terminals are connected to an 
NT1 via a passive bus 

• A multi-terminal installation where several terminals are connected to an 
NT1 or an NT2 in a star configuration 

At the outset the ISIS Network Model will use a single point installation between the ISDN 
Telephone and the VSAT. This will permit the use of up to 1000m of cable to assure 
maximum of 6 dB attenuation at 96 kHz. This cable length will provide a signal round trip 
delay of 10 to 42 microseconds from the transmitter to the receiver. 

The S-interface is modeled by a single process (SIF) that delays the message as a function 
of the round trip delay. For the ISIS Network Model all protocol messages are sent on the 
D channel and therefore have a constant delay once the D channel contention has been 
resolved. 

4.3.8 U-Interface Components 

The U-interface component provides the transfer of information that takes place on the two 
wire circuit between the ISTA and the VSAT. For the ISIS Network Model, echo 
cancelling is used. Echo cancelling is characterized by simultaneous transmission in both 
direction, full duplex, elimination of echo, and a bit rate of 160 kbps. The 144 kbps are 
used for the 2B+D BRI information and the other 16 kbps is used for synchronization, 
operations, and maintenance. 

The U-interface is modeled by a single process (UIF) that delays the messages as a 
function of its BRI rate. For the ISIS Network Model all protocol messages are sent on the 
D channel and therefore have a constant delay. 
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4.4 


ISIS Model Processes 


This section describes the processes that make up the communication components of the 
ISIS Network Model. These processes are the software modules that implement the 
communication functions being modeled. As indicated above, each of these 
processes/modules is reused in a number of the communication components that make up 
the ISIS Network Model. The same description format is used in order to provide a direct 
comparison between the processes For the ease of reference the processes are listed in 
alphabetical order. 

4.4.1 ACTSBBP Process 


The ACTSBBP process accepts BBP command messages; takes the appropriate action of 
assigning and relinquishing B-channel resources; sends appropriate BBP status messages. 


Inputs: BBP Command Messages 

Outputs: BBP Status Messages 

Operation: Accept BBP Command Message from ACTSOW Process 

• Assign B-Channel 

• Relinquish B-Channel 

• Send BBP Status Message 

• Return 


Parameters: Number of B-Channels Available for assignment 

Processing Time for each accept, assign, relinquish and send action 


4.4.2 ACTSOW Process 


The ACTSOW process accepts IBOW messages from the VSAT and OBOW messages 
from the MGS via the uplink receiver (Rx30) and routes them to the MGS and VSAT 
downlink transmitters (Tx20), respectively. The ACTSOW process also accepts BBP 
command messages from the MGS on its uplink receiver (Rx30) and routes them to the 
ACTS baseband processor (ACTSBBP). It also accepts BBP status messages from the 
ACTS BBP and routes them to the MGS downlink transmitter (Tx20). 

Inputs: IBOW, OBOW, BBP Command, and BBP Status Messages 

Outputs: IBOW, OBOW, BBP Command, and BBP Status Messages 

Operations: Accept IBOW Message from Rx30 Process 

• Route IBOW Message to Tx20 Process 

• Return 

Accept OBOW Message from Rx30 Process 

• Route OBOW Message to Tx20 Process 

• Return 

Accept BBP Command Message from Rx30 Process 

• Route BBP Command Message to ACTSBBP Process 

• Return 

Accept BBP Status Message from ACTSBBP Process 

• Route BBP Status Message to Tx20 Process 

• Return 
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Parameters: Processing Time for each accept and route action 

4.4.3 1430 Process 


The 1430 process is based on the CCITT Recommendation 1,430. Basic User Interface - 
Laver 1 Specification , for the point-to-point operation at Layer 1 for a single transmitter 
(source) and receiver (sink) are active at one time. The nominal transmitted bit rate at the 
interface is cited as 192 kbps in both direction of transmission. For the ISIS Network 
Model, the activation/deactivation sequence shown in Figure 4.4.3-1, "Layer 1 Protocol 
Activation/Deactivation" will be used. The processing of associated management primitives 
is reserved for future implementations. 


The 1430 process will propagate all higher layer messages without error to and from the S- 
interface via the Info3 and Info4 transmissions in F7 -Activated and G3- Active states. 


Inputs PH- ACTIVATE, PH-ACTIVATE-IND, PH-DEACTTV ATE IND, INFOO, 

INF02, INF03[TE— >NE], and INF04[TE<-NE] Messages 
Outputs: PH-ACTIVATE IND, PH-DEACTIV ATE IND, INFOO, INF02, 

INF03[TE->NE], and INF04[TE<— NE] Messages 
Operations: Accept PH- ACTIVATE from Q921 Process 

• if F3-Deactivated State 

• Start T3-Timer 

• Send Infol(non-synced) to SIF Process 

• Set F4-A waiting Signal State 

• else Return 

Accept Infol from SIF Process 

• if G3-Deactivated State 

• Send Info2 (within lsec) to SIF Process 

• Start T1 -Timer 

• Set G2-Pending Activation State 

• else Return 

Accept Info2 from SIF Process 

• if F4- A waiting Signal State 

• Send InfoO (within 5 millisec) to SIF Process 

• Set F5-Identifying Input 

• Send Info3 (within 100 millisec of Info2 to SIF Process) 

• Set F6-Synchronized 

• else Return 

Accept Info3 from SIF Process 

• if G3-Active State 

• Send [Info3] to Q921 Process 

• Return 

• if G3-Pending Activation State 

• Send Info4 (within 500 millisec) to SIF Process 

• Send PH- ACITV ATED IND to Q92 1 Process 

• Set G3-Active State 

• else Return 

Accept Info4 from SIF Process 
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• if F7- Activated State 

• Send [Info4] to Q921 Process 

• Return 

• if F6-Synchronized State 

• Send PH-ACIWATED IND to Q92 1 Process 

• Set F7-Activated State 

• else Return 

Parameters: Values of Tl, T2, and T3 timers 

Processing Time for each accept, if, and send action 


4.4.4 1431 Process 


The 1431 process is based on the CCIT T Recommendation 1.431. Primary R ate User- 
Network Interface - Laver 1 Specification, for the point-to-point operation at Layer 1 for a 
single transmitter (source) and receiver (sink) are active at one time. The nominal 
transmitted bit rate at the interface is cited as 1544 kbps in both direction of transmission. 


The interfaces for the primary rate user-network interface is active at all times. No 
activation/deactivation are applied to the interface. For the ISIS Network Model, the FI - 
Operational State and the G1 -Operational State are assumed to be active. The other fault 
condition states are left for future implementations. 


Inputs: Layer 2 and UIF Messages 

Outputs: Layer 2 and UIF Messages 

Operations: Accept Layer 2 Message from UIF Process 

• if G1 -Operational State 

• Send Layer 2 Message to Q921 Process 

• Return 

• else Return 

Accept Layer 2 Message from UIF Process 

• if FI -Operational State 

• Send Layer 2 Message to Q921 Process 

• Return 

• else Return 


Parameters: Processing Time for each accept, if, and send action 

4.4.5 ISDNTel Process 


The ISDNTel process is based on human interface that requests and terminates ISDN 
telephone calls. The ISDNTel process acts as a source by generating a Layer 3 protocol 
sequence that triggers the Q931 process. The timing and content of these initiating 
messages are obtained from the scenario traffic file (STF). 

Inputs: Scenario Traffic File (STF). 

Outputs: Request and Terminate Messages 

Operations: Read STF 

• Send Q931 Message to Q931 process 

• loop 
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Accept Q931 Message from Q931 Process 

• Set ISDNTel Internal State 

• Send Q93 1 Response Message to Q931 Process 

• Return 

Parameters: Processing Time for each accept and send action 


4.4.6 ISUP Process 

The ISUP process provides its end-user with the capability to establish, supervise, and 
terminate basic bearer services. As currently defined, the ISUP is restricted to 64 kbps 
switched connections. The message structures and functional procedures for carrying out 
ISUP tasks are given in CCITT Recommendations Q.730, Q761 to Q.764, and Q.766. 
For the ISIS Network Model using ACTS as a basis, the ISUP functions are performed 
within the VSAT. 

Inputs: Q93 1 and ISUP Messages 

Outputs: Q93 1 and ISUP Messages 

Operations: Accept Q931 Message from Q931 Process 

• Send ISUP Message to VSATOW Process 

• Return 

Accept ISUP Message from VSATOW Process 

• Send Q931 Message to Q931 Process 

• Return 

Parameters: Processing Time for each accept and send action 

4.4.7 MGSOW Process 

The MGSOW process accepts IBOW and BBP Status messages from the downlink 
receivers (Rx30) and routes them to the MGSProc. The MGSOW process accepts OBOW 
and BBP Command messages from the MGSProc and routes them to the uplink transmitter 
(Tx30). 

Inputs: IBOW, OBOW, BBP Command, and BBP Status Messages 

Outputs: IBOW, OBOW, BBP Command, and BBP Status Messages 

Operations: Accept IBOW Message from Rx20 Process 

• Route IBOW Message to MGSProc Process 

• Return 

Accept BBP Status from Rx20 Process 

• Route BBP Status Message to MGSProc Process 

• Return 

Accept OBOW Message from MGSProc Process 

• Route OBOW Message to Tx30 Process 

• Return 

Accept BBP Command from MGSProc Process 
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♦ Route BBP Command Message to Tx30 Process 

• Return 


Parameters: Processing Time for each accept and route action 

4.4.8 MGSProc Process 


The MGSProc process accepts IBOW and BBP Status messages and converts them to 
OBOW and BBP command messages, respectively. 


Inputs: IBOW and BBP Status Messages 

Outputs: OBOW and BBP Command Messages 

Operation: Accept IBOW Message from MGSOW Process 

• Convert IBOW Message to OBOW Message 

• Send OBOW Message to MGSOW Process 

• Return 

Accept BBP Status Message from MGSOW Process 

• Convert BBP Status Message to BBP Command Message 

• Send BBP Command Message to MGSOW Process 

• Return 

Parameters: Processing Time for: each accept, convert, and send action 

4.4.9 Prop Process 

The Prop process models all space propagation aspects for the ISIS Network Model. The 
distance between transmitter and receiver reduces the amount of energy (SigPropEnergy) 
available at the receiver. The weather conditions also affect the SigPropEnergy and are 
included in this Prop process. 


Inputs: Any Message from TxAnt** Process 

Outputs: Input Message to RxAnt** Process 

Operations: Accept Message from TxAnt** Process 


if Communication Component is MGS 

• Adjust SigPropEnergy by Prop(MGSLoc,ACTSLoc) 

• Adjust SigPropEnergy by Prop(WeaMGS) 

• Send Message to ACTS RxAnt30 Process 

• Return 
else Return 

Accept Message from TxAnt** Process 


• if Communication Component is VSAT 

• Adjust SigPropEnergy by Prop(VSATLoc,ACTSLoc) 

• Adjust SigPropEnergy by PropfWeaVSAT) 

• Send Message to ACTS RxAnt30 Process 

• Return 

• else Return 

Accept Message from TxAnt** Process 


if Communication Component (input) is ACTS 
• if Communication Component (output) is MGS 
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• Adjust SigPropEnergy by Prop(MGSLoc,ACTSLoc) 

• Adjust SigPropEnergy by Prop(WeaMGS) 

• Send Message to MGS RxAnt20 Process 

• Return 

• if Communication Component (output) is VS AT 

• Adjust SigPropEnergy by Prop(VSATLoc,ACTSLoc) 

• Adjust SigPropEnergy by Prop(WeaVSAT) 

• Send Message to VSAT RxAnt20 Process 

• Return 

• else Return 

Parameters: Processing Time for each accept, if, and send action 

WeaVSAT = weather between VSAT and ACTS 
WeaMGS = weather between MGS and ACTS 

4.4.10 Q921 Process 

The Q921 process provides data link peer-to-peer exchange of information of the Link 
Access Procedures on the D-channel, LAPD. The CCITT Recommendation 0.921. ISDN 
User-Network Interface - Data Link Laver Specification provide a description of the 
procedures and function of LAPD. For the ISIS Network Model this LAPD protocol is 
used in the ISDNTel, ISTA, and the VSAT communications component to assure error free 
peer-to-peer protocol message exchanges in the D-channel. 

Inputs: 1430, 143 1 , and Q93 1 Messages 

Outputs: 1430, 1431, and Q93 1 Messages 

Operations: Accept 1430 Message from 1430 Process 

• Concert 1430 Message to Q931 Message 

• Send Q931 Message to Q931 Process 

• Return 

Accept 143 1 Message from Q43 1 Process 

• Concert 1431 Message to Q931 Message 

• Send Q931 Message to Q931 Process 

• Return 

Accept Q931 Message from Q931 Process 

• if Communication Component is ISDNTel 

• Convert Q931 Message to 1430 Message 

• Send 1430 Message to QI430 Process 

• if Communication Component is ISTA 

• Concert Q931 Message to 1430 Message 

• Send 1430 Message to QI430 Process 

• if Communication Component is VSAT 

• Concert Q931 Message to 1431 Message 

• Send 143 1 Message to QI43 1 Process 

• else Return 

Parameters: Processing Time for each accept, if, and send action 
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4.4.11 


Q931 Process 


The Q931 process provides procedures for establishing, maintaining, and clearing network 
connections at the ISDN user-network interface. Messages are exchanged over the D 
channel. The CCITT Recommendation 0.931. ISDN User-Network Interface Laver 3 
Specification for Basic Call Control p rovide a description of the procedures and functions. 
For the ISIS Network Model this Q.931 protocol is used in the ISDNTel, ISTA, and the 
VSAT communications component to assure error free peer-to-peer protocol message 
exchanges in the D channel. 

Inputs: ISDNTel, ISUP, Q921, and Q931 Messages 

Outputs: ISDNTel, ISUP, Q921, and Q931 Messages 

Operations: Accept ISDNTel Message from ISDNTel Process 

• Convert ISDNTel Message to Q921 Process 

• Send Q921 Message to Q921 Process 

• Return 

Accept Q931 Message from ISUP Process 

• Convert ISDNTel Message to Q921 Process 

• Send Q921 Message to Q921 Process 

• Return 

Accept Q921 Message from Q921 Process 

• if Communication Component is ISDNTel 

• Convert ISDNTel Message to Q921 Process 

• Send Q931 Message to ISDNTel Process 

• Return 

• if Communication Component is ISTA 

• Convert ISDNTel Message to Q921 Process 

• Send Q931 Message to Q931 Process 

• Return 

• if Communication Component is VSAT 

• if Process is Q92 1(a) 

• Convert ISDNTel Message to Q921 Process 

• Send Q921 Message to 1430 Process 

• Return 

• if Process is Q92 1 (b) 

• Convert ISDNTel Message to Q921 Process 

• Send Q93 1 Message to ISUP Process 

• Return 

• else Return 

Accept Q931 Message from Q931 Process 

• if Process is Q93 1 (a) 

• Convert ISDNTel Message to Q921 Process 

• Send Q931 Message to Q931(b)Process 

• Return 

• if Process is Q93 1 (b) 

• Convert ISDNTel Message to Q921 Process 

• Send Q93 1 Message to Q93 1 (a)Process 

• Return 

• if Communication Component is ISTA 

• Convert ISDNTel Message to Q921 Process 
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• Send Q931 Message to Q931 Process 

• Return 

• if Communication Component is VS AT 

• Convert ISDNTel Message to Q921 Process 

• Send Q93 1 Message to ISUP Process 

• Return 

• else Return 

Parameters: Processing Time for each accept, if, and send action 

4.4.12 Rx ** Process 

The Rx** process models all receivers of the ISIS Network Model. The "**" notation is 
place holder for 20 and 30 that represent the downlink and uplink frequencies of the ISIS 
Network Model. The receivers have a sensitivity parameter that set the energy values 
below which a signal is not accepted. For signal energy below the receiver sensitivity the 
whole message is consider loss. That message is logged to the MSave file as a lost 
message together with the time and subsystem that failed it. The message is not 
propagated. 

Inputs: Any Message from RxAnt** 

Outputs: Input Message to ACTSOW or MGCOW or VSATOW 

Operations: Accept Message from RxAnt** Process 

• if MsgProp Value > Rx** Sensitivity 

• if Communication Component is ACTS 

• Send Message to ACTSOW Process 

• Return 

• if Communication Component is MGS 

• Send Message to MGSOW Process 

• Return 

• if Communication Component is VSAT 

• Send Message to VSAT Process 

• Return 

• else Return 

Parameters: Processing Time for each accept, if, and send action 

Rx**Sensitivity as receiver threshold 

4.4.13 RxAnt ** Process 

The RxAnt** process models all receiver antennas of the ISIS network Model. The "**" 
notation is place holder for 20 and 30 that represent the downlink and uplink frequencies of 
the ISIS Network Model. The receiver antennas have a number of parameters that reflect 
its design. RxAnt**BW represents the antenna beam; RxAnt**G sets the antenna gain; 
RxAnt**Lat and RxAnt**Lon indicate the antenna subpoint location; RxAnt**Dwell 
represents the antenna dwell time at a location; RxAnt**HopFreq represents its hop 
frequency; and RxAnt**Scan provides the antenna scan rate. To be received by the 
corresponding receiver the transmitted energy must coincide with all these antenna 
parameters. 

Inputs: Any Message from Prop Process 

Outputs: Input Message to Rx** Process 

Operations: Accept Message from Prop Process 
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• if Communication Component is MGS 

• if MGS RxAnt20 pointed at ACTS Satellite 

• Adjust SigPropEnergy by RxAnt20Gain 

• Send Message to MGS Rx20 Process 

• Return 

• else Return 

Accept Message from Prop Process 

• if Communication Component is VSAT 

• if VSAT RxAnt20 pointed at ACTS Satellite 

• Adjust SigPropEnergy by RxAnt20Gain 

• Send Message to VSAT Rx20 Process 

• Return 

• else Return 

Accept Message from Prop Process 

• if Communication Component is ACTS 

• if ACTS RxAnt30 pointed at transmitter subpoint 

• Adjust SigPropEnergy by RxAnt30Gain 

• Send Message to ACTS Rx30 Process 

• Return 

• else Return 

Parameters: Processing Time for each accept, if, and send action 

RxAnt**BW = antenna beam 
RxAnt**Gain = antenna gain 
RxAnt**Lat = antenna latitude 
RxAnt**Lon = antenna longitude 
RxAnt**Dwell = antenna dwell time 
RxAnt**HopFreq = antenna hop frequency 
RxAnt**Scan = antenna scan rate. 

4.4.14 SIF Process 

The SIF process models the S-interface between the user ISDN Telephone and the ISDN 
Satellite Terminal Adapter (ISTA). For the ISIS network Model, the SIF Process provides 
basic rate ISDN (BRI) connectivity for the 1.430 protocol messages. 

Inputs: 1430 Protocol Messages from the 1430 Process 

Outputs: 1430 Protocol Messages to the 1430 Process 

Operations: Accept 1430 Message from 1430 Process 

• Send 1430 Message to 1430 Process 

• Return 

Parameters: Processing Time for each accept and send action 


4.4.15 Tx ** Process 

The Tx** process models all transmitters of the ISIS Network Model. The "**" notation is 
place holder for 20 and 30 that represent the ISIS Model downlink and uplink frequencies, 
respectively. The transmitters are modeled as isotropic radiators that impart the messages 
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being transmitted with SigPropEnergy value. This value is mitigated by the TxAnt**, 
propagation (Prop) and RxAnt** processes, and finally used by the Rx** process to accept 
the message. . 

Inputs: Messages from ACTSOW or MGCOW or VSATOW Process 

Outputs: Message to TxAnt** 

Operations: Accept Message from ACTOW I MGSOW I VSATOW Process 

• Set SigPropEnergy for Message 

• Send Message to TxAnt** Process 

• Return 

Parameters: Processing Time for each accept, if, and send action 

SigPropEnergy for energy associated with message 

4.4.16 TxAnt ** Process 

The TxAnt** process models all transmitter antennas of the ISIS network Model. The 
"**" notation is place holder for 20 and 30 that represent the ISIS Model downlink and 
uplink frequencies, respectively. The transmitter antennas have a number of parameters 
that reflect its design. TxAnt**BW represents the antenna beam; TxAnt**Gain sets the 
antenna gain; TxAnt**Lat and TxAnt**Lon indicate the antenna subpoint location; 
TxAnt**Dwell represents the antenna dwell time at a location; TxAnt* *HopFreq represents 
its hop frequency; and TxAnt**Scan provides the antenna scan rate. To be received by the 
corresponding receiver antenna, the transmitted antenna energy must coincide with all these 
antenna parameters. 

Inputs: Any Message from Tx** Process 

Outputs: Input Message to Prop Process 

Operations: Accept Message from Tx** Process 

• Check RxAnt** and TxAnt** coincidence 

• Adjust SigPropEnergy by TxAnt**Gain 

• Send Message to Prop Process 

• Return 

Parameters: Processing Time for each accept, check, and send action 

TxAnt* *BW = antenna beam 
TxAnt**Gain = antenna gain 
TxAnt**Lat = antenna latitude 
TxAnt**Lon = antenna longitude 
TxAnt**Dwell = antenna dwell time 
TxAnt**HopFreq = antenna hop frequency 
TxAnt**Scan = antenna scan rate. 

4.4.17 UIF Process 

The UIF process models the U-interface between the ISDN Satellite Terminal Adapter 
(ISTA) and the VSAT. For the ISIS network Model, the UIF process provides primary 
rate ISDN (PRI) connectivity for the 1.431 protocols. 

Inputs: 1431 Protocol Messages from the 1431 Process 

Outputs: 143 1 Protocol Messages to the 143 1 Process 

Operations: Accept 1431 Message from 1431 Process 
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• Send 1431 Message to 1431 Process 

• Return 

Parameters: Processing Time for each accept and send action 

4.4.18 VSATOW Process 

The VSATOW process accepts ISUP and OBOW messages and converts them to IBOW 
and ISUP messages, respectively. 

Inputs: ISUP and OBOW Messages 

Outputs: IBOW and ISUP Messages 

Operations: Accept ISUP Message from ISUP Process 

• Converts ISUP Message to IBOW Message 

• Sends IBOW Message to Tx30 Process 

• Return 

Accept OBOW Message from Rx20 Process 

• Converts OBOW Message to ISUP Message 

• Sends ISUP Message to ISUP Process 

• Return 

Parameters: Processing Time for each accept, convert, and send action 

4.5. Complete ISIS Network Model 

Figure 4.5-1, "Complete ISIS Model" shows all the components of the ISIS model 
previously described into a single end-to-end model. The figure shows the S-interface 
protocols expanded to include the activation and deactivation sequences using the F-State 
and G-State notation. In its activated mode, the S-interface passes BRI traffic without 
error. The U-interface on the other hand is assumed to be fully operational state at all time 
passing normal frame PRI traffic without errors. Figure 4.5-1 exposes the end-to-end 
protocol flow sequences through all the ISIS communication component models separating 
the uplink and downlink chains. The two views of the ISDN Telephone, ISTA, VS AT, 
and ACTS can be combined envoking superposition to form the complete communication 
component entity. The B channel resources are shown in Figure 4.5-1, page 2 of 3. The 
number of B channels available is one of the major design parameters for an advanced 
ISDN communications satellite together with the values for antenna parameters, timers, and 
processing delays. 


4-18 








4-20 


OKtCnMAL PAGE IS 
OF POOH QUALITY 






4-21 


ORIGINAL PAGE iS 

OF POOR QUALITY 




SECTION 5 


SUMMARY 


5.1 General 

This task completion report for the ISIS Network Model presented the complete end-to-end 
protocol model suitable for discrete event simulation. The model is applicable to the the 
Interim Service ISDN Satellite (ISIS) and the Full Service ISDN Satellite (FSIS). The 
ultimate aim of this aspect of the SCAR Program is the design of a new advanced ISDN 
communications satellite. The technical and operational parameters for this ISDN 
advanced communications satellite design will be obtained from an engineering software 
model of the major subsystems of the ISDN communications satellite architecture. 
Discrete event simulation experiments will be performed with these ISIS and FSIS models 
using various traffic scenarios, technical parameters, and operational procedures. The data 
from those simulations will be analyzed using the performance measures discussed in 
previous NASA SCAR reports. 

5.2 Review 

After an introduction that provided the background and scope of this NASA SCAR 
Program, the use of modeling and simulation to determine the parameters for the advanced 
ISDN communications satellite design was presented. An overview of the modeling and 
simulation tasks included a brief description of the four software programs for the effort. 
The two main sections of this task completion report are the Network Modeling and the 
ISIS Network Model. 

The Network Modeling Section described the generic approach and methodology for 
modeling communication systems using discrete event simulation techniques. Four distinct 
phases are associated with network modeling: database generation, scenario generation, 
simulation run, and product generation. Emphasis was placed on the simulation run phase. 
The associations between communication subsystems and software modules for the models 
and simulations were developed. 

The ISIS Network Model Section used the context of the modeling methodology developed 
above to form a framework for the ISIS Network Model. ISIS communication component 
models were defined and presented. Software modules were associated with ISDN 
communication processes that implemented the communication functions within these 
communication components. Each communications process was defined in terms of 
inputs, outputs, operations, and parameters. The CCl’lT recommendations were used as 
the basis of the communication processes and "Approach 2A" was used as the ACTS 
communications architecture. A complete ISIS Network Model diagram was developed 
depicting every process of every communication component. 

5.3 Continuing Efforts 

The research in network modeling is continuing using the FSIS Network Model 
architecture described in Figure 1.1-1. It is anticipated that the FSIS Network Model will 
re-use many of the same communication processes developed for ISIS. The evolutionary 
refinement achieves by ISIS model will be passed directly to the FSIS model. The task 
completion report for the FSIS Network Model is due to NASA by March 1, 1992. 
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